1. Field of the Invention
The present invention relates generally to data networks, and more particularly to a technique for implementing asymmetric routing and resource allocation in a network address translation (NAT) environment implemented on a data network.
2. Background
Private networks are commonly connected to the Internet through one or more routers so that hosts (PCs or other arbitrary network entities) on the private network can communicate with nodes on the Internet. Typically, the host will send packets to locations both within its private network and on the Internet. To receive packets from the Internet, a private network or a host on that network must have a globally unique 32-bit IP address. Each such IP address has a four octet format. Typically, humans communicate IP addresses in a dotted decimal format, with each octet written as a decimal integer separated from other octets by decimal points.
Global IP addresses are issued to enterprises by a central authority known as the Internet Assigned Number Authority (“IANA”). The LANA issues such addresses in one of three commonly used classes. Class A IP addresses employ their first octet as a “netid” and their remaining three octets as a “hostid.” The netid identifies the enterprise network and the hostid identifies a particular host on that network. As three octets are available for specifying a host, an enterprise having class A addresses has 224 (nearly 17 million) addresses at its disposal for use with possible hosts. Thus, even the largest companies vastly underuse available class A addresses. Not surprisingly, Class A addresses are issued to only very large entities such as IBM and ATT. Class B addresses employ their first two octets to identify a network (netid) and their second two octets to identify a host (hostid). Thus, an enterprise having class B addresses can use those addresses on approximately 64,000 hosts. Finally, class C addresses employ their first three octets as a netid and their last octet as a hostid. Only 254 host addresses are available to enterprises having a single class C netid.
Unfortunately, there has been such a proliferation of hosts on the Internet, coupled with so many class A and B licenses issued to large entities (who have locked up much address space), that it is now nearly impossible to obtain a class B address. Many organizations now requiring Internet access have far more than 254 hosts—for which unique IP addresses are available with a single class C network address. It is more common for a mid to large size enterprise to have 1000 to 10,000 hosts. Such companies simply can not obtain enough IP addresses for each of their hosts.
To address this problem, a Network Address Translation (“NAT”) protocol has been proposed. See K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” RFC 1631, Cray Communications, NTT, May 1994 which is incorporated herein by reference for all purposes. NAT is based on the concept of address reuse by private networks, and operates by mapping the reusable IP addresses of the leaf domain to the globally unique ones required for communication with hosts on the Internet. Further, to implement NAT, a translation system must be provided between the enterprise private network and the Internet. In implementation, a local host wishing to access the Internet receives a temporary IP address from a pool of such addresses available to the enterprise (e.g., Class C 254 addresses). While the host is sending and receiving packets on the Internet, it has a global IP address which is unavailable to any other host. After the host disconnects from the Internet, the enterprise takes back its global IP address and makes it available to other hosts wishing to access outside networks.
FIG. 1 shows a portion of a private network 100. As illustrated in FIG. 1, private network portion 100 includes a plurality of gateway routers (e.g., 104a, 104b) which are configured to perform network address translation for allowing hosts (e.g., H1, H2) or other network devices in the private network to communicate with external nodes (e.g., N1, N2) via a wide area network 110 such as, for example, the Internet.
In the example of FIG. 1, the NAT gateway routers 104a, 104b may be configured as active and standby routers using a Hot Standby Router Protocol (HSRP) such as that described in U.S. Pat. No. 6,108,300, herein incorporated by reference in its entirety for all purposes. The HSRP protocol provides redundancy and fail-over support for the NAT routers 104a, 104b. Thus, for example, if the active NAT router (e.g., NAT1) fails, the standby NAT router (e.g., NAT2) is able to take over the responsibilities of the failed NAT router. As illustrated in the example of FIG. 1, NAT gateway router 104a may be configured as the active gateway router, and NAT gateway router 104b may be configured as the standby gateway route which is configured to take over the functions of the active gateway router 104a during times when the active gateway router is unavailable.
Generally, conventional NAT routers manage and translate address/port information as packets travel from one realm to another. For continuous flows, this translation information is stored in a repository until that flow expires. As applications become more complex, the flow attachment records include additional context sensitive information that may be necessary while the flow is unexpired. Typically, NAT routers record all such information. However, if, for any reason, a NAT router fails or has to be restarted, the translation repository and context information on that router will be lost, thereby isolating the end points and making the flow unrecoverable due to loss of NAT Table information for these flows. As a result, LAN clients which had been using the failed NAT router will have to restart their applications in order to re-establish connectivity to the Internet using an alternate NAT router. Moreover, in most conventional NAT systems, the translation repository or address translation table needs to be continually updated on a per-packet basis. This typically results in thousands of translation updates per second, which makes off-box NAT redundancy updates impractical.
Additionally, communication between internal nodes of the private network and external nodes (i.e., nodes external to the private network) is typically achieved using a symmetric routing protocol whereby all incoming and outgoing packets in to and out from the private network are routed through the active gateway router (e.g., gateway router 104a). One reason for this is that, according to conventional techniques, the active gateway router is designed to be responsible for handling and maintaining all information relating to traffic flows between internal and external nodes. Such information may include, for example, network address translation information, session information, application specific information, timer information (e.g., session timeout information), etc.
It will be appreciated, however, that symmetric routing protocol requirements may result in increased and burdensome traffic loads being imposed upon the active gateway router. Additionally, such symmetric routing protocols may also result in unnecessary routing limitations being imposed upon external gateway routers. Accordingly, it will be appreciated that there exists a continual need to improve upon routing and network address translation mechanisms which are implemented in redundant routing environments in order, for example, to improve traffic flows between public networks and private networks.